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Protocol Header Gonstruction And/Or 
Removal For Messages In Wireless Communications 

Technical Field 

This invention is generally related to reconstruction and/or removal of protocol 
headers in messages in wireless communications. , 

Backgroimd 

Packet data networks are widely used to link various types of network elements, such 
as personal computqrs^' servers, network telephones, Internet appliances, and so forth. 
Examples of data networks include private networks (such as local area networks or wide 
area networks) and public networks (such as the Intemet). Common forms of 
commimications between network elements across packet data networks include electronic 
mail, file transfer, web browsing, and other exchanges of data. More recently, with the 
increased capacity and reliability of packet data networks, audio communications (such as 
voice communications), video commimications (such as video conferencing), and other forms 
of real-time interactive or streaming commimications are becoming more common over 
packet data networks. , 

With advancements in wireless communications networks, efficient packet-switched 
communications over wireless networks have also become possible. Traditionally, wireless 
communications networks have been implemented as circuit-switched networks. In a circuit- 
switched network, a channel portion (such as a time slot) between two endpoints (e.g., two 
mobile stations) is occupied for the duration of the coimection between the endpoints. 

Several packet-switched wireless technologies have been proposed to provide more 
efficient connections between a mobile station and a packet data network, such as an Intemet 
Protocol (IP) network. One such technology is the General Packet Radio Service (GPRS) 
technology, which provides for packet services in GSM (Global System for Mobile) 
networks, UMTS (Universal Mobile Telecommunications System) networks, or GERAN 
(GSM/EDGE radio access network) network. EDGE, which stands for Enhanced Data Rate 
for Global Evolution, is compatible with GSM and TIA/EIA-136 TDMA (time-division 
multiple access) wireless commimications technologies. UMTS is based on the wideband 
code-division multiple access (W-CDMA) wireless communications technology. 
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Packet services that are provided by such packet-switched wireless technologies 
include traditional packet services such as web browsing, electronic mail, file transfer, and so 
forth. Additionally, real-time and interactive packet services, such as telephony services 
(e.g., voice-over-IP services) are also provided. In voice-over-IP communications, voice 
traffic is carried in packets (referred to as "packet-switched voice traffic"). 

One of the issues associated with carrying packet-switched voice traffic over a 
wireless link or air interface between the mobile station and radio, network controller is that 
new channel coding and interleaving schemes may have to be developed. Typically, traffic 
channels that carry circuit-switched traffic have predetermined and standardized coding and 
interleaving schemes. As example coding and interleaving scheme is described in the GSM 
05.03 Specification (Version 8.50 Release 1999). Developing and adopting new standards 
for packet-switched voice traffic (and other bearer traffic) can be a relatively long process 
requiring several tounds of negotiation between different parties. Also, equipment that has 
been manufactured to support old standards may not be able to support new, modified 
standards. 

Packet-switched traffic (e.g., voice) is accompanied by overhead information in the 
, form of protocol headers, e.g., Real-Time Protocol (RTP) headers. User Datagram Protocol 
(UDP) headers, and Internet Protocol (IP) headers. Such headers are rather large and can 
take up substantial amounts of bandwidth, especially since the protocol headers are 
commimicated in each and every packet. As a result, commtmication of such headers over 
the air interface between a mobile station and radio equipment causes a reduction of the 
spectral efficiency of the air interface. 

Summarv 

In general, according to one embodiment, a method of communicating data over a 
wireless link between a mobile station and a wireless access system comprises 
commimicating, over the wireless link, control signaling for setting up a packet-switched 
communications session between the mobile station and an endpoint. Packets containing 
real-time data are commimicated over the wireless link, with at least one protocol header 
associated with the packet-switched communications being removed fi*om each packet before 
communicating the packet over the wireless link. 
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Other or alternative features will become apparent from the following description, 
from the drawings and from the claims. . 

Brief Description Of The Drawings 

Fig. 1 is a block diagram of an example of a wirelesis conMnunications network. 

Fig. 2 illustrates an Internet Protocol (IP) packet for carrying real-time bearer traffic. 

Fig. 3 is a message flow diagram of a process of establishing communications 
between a mobile station and another endpoint in the wifeless communications network of 
Fig. 1, in accordance with an embodiment. 

Figs. 4 and 5 are flow diagrams of processes for receiving and transmitting bearer 

data. 

Fig. 6 is a block diagram of components in a mobile station and a radio network 
controller, in accordance with an example. 

t 

■ • I . .. ■ 

Detailed Description 

In the following description, numerous details are set forth to provide an 
' understanding of the present invention. However, it will be imderstood by those skilled in the 
art that the present invention may be practiced without these details and that mmierous 
variations or modifications from the described embodiments may be possible. 

Referring to Fig. 1, a communications network 10 includes a wireless core network 1 1 
that enables conrniimications with mobile stations (e.g., 16, 18, 20, and 22). The wireless 
core network 1 1 includes radio access network (RAN) equipment 12 and 14 for 
commimicating with the mobile stations 16, 18, 20 and 22 over wireless links. A wireless 
link is also referred to as an air interface. The radio access network equipment 12 includes a 
GSM/EDGE (Global System for Mobile/Enhanced Data Rate for Global Evolution) radio 
access network (GERAN) system. GERAN provides for enhanced data rates for best-effort 
services (e.g., web browsing, electronic mail, and so forth) and real-time traffic (e.g., voice- 
over-Internet Protocol or voice-over-IP). A version of IP, referred to as IPv4, is described in 
Request for Comments (RFC) 791, entitled "Intemet Protocol," dated September 1981. 
Another version of IP is IPv6, which is described in RFC 2460, "Internet Protocol, Version 6 
(IPv6) Specification," dated December 1998. 
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The radio access network equipment 14 includes a UMTS (Universal Mobile 
Telecommunication System) terrestrial radio access network (UTRAN) system. The 
UTRAN system 14 is based on the wideband code-division multiple access (W-CDMA) 
technology. 

The GERAN system 12 includes a GERAN base station transceiver (or radio) and a 
GERAN radio net\vork controller (RNC), and the UTRAN system 14 includes a UTRAN 
base station transceiver and a UTRAN radio network controller (RNC). More generally, a 
"wireless access systerti" refers to any system (such as the GERAN or UTRAN base station 
transceiver and RNC), implemented as one or plural modules, that is capable of 
commimicating with mobile stations over defined chaimels on wireless links. 

The GERAN radio network controller is coupled to a serving GPRS (General Packet 
Radio Service) support node (SGSN) 24 over a Gb link or an lu link (specifically an lu-ps 
, link for packet-switched data). Signaling and' user data can be communicated between the 
GERAN radio network controller and SGSN 24 over each of the Gb and lu links. The 
UTRAN radio network controller is coupled to the SGSN 24 over an lu link (specifically an 
lu-ps link for packet-s\vitched data). The SGSN 24 (along with the GGSN 26 and the RNC 
portions of the GERAN system 12 and UTRAN system 14) controls, the establishment, 
processing, and termination of packet-switched communications sessions between mobile 
stations 16, 18, 20 and 22 and another endpoint. 

The SGSN 24 is in turn coupled to a gateway GPRS support node (GGSN) 26 over a 
Gn interface. The GGSN 26 acts as a gateway between the wireless core network 1 1 and a 
packet network 28, such as the Litemet or other type of packet network or even another 
wireless core network. The GGSN 26 is coupled to an edge or border gateway router (not 
shown) in the packet data network 28 over a Gi interface. The packet network 28 is coupled 
to various endpoints, such as a PC telephone 30 and a user station 32 (e.g., a computer 
system). 

The GGSN 26 is also coupled to a media gateway (MGW) 34 over a Gi interface. 
The media gateway 34 acts as a gateway for commimications of bearer traffic between (1) the 
wireless core network 1 1 and a circuit-switched network such as a public switched telephone 
network (PSTN) 36 and (2) the wireless core network 1 1 and the Internet 28 (in the event that 
transcoding is required for wireless Internet technology to wireless/landline Intemet 
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telephone calls). The PSTN 36 is coupled to various terminals 38, such as telephones, and 
the Internet 28 is coupled to various terminals 30, 32, such as PC telephones. 

The wireless core network 1 1 also includes a call state control function (CSCF) 
module 40 that provides call control for a packet-switched communications session, hi some 
embodiments, the CSCF module 40 is a (Session Initiation Protocol) SIP proxy or server that 
receives call requests on behalf of other entities, resolves logical addresses or identifiers in 
the call requests, and forwards the call requests to intended destinations. SIP defines a call 
establishment protocol that can be used to initiate call sessions as well as to invite members 
to a session that may have been advertised by some other mechanism, such as electronic mail, 
news groups, web pages, and other mechanisms. A version of SIP is described in RFC 2543, 
entitled "SIP: Session Initiation Protocol," dated August 1999. In other embodiments, other 
types of call control protocols or standards C3i\ be used, such as the H.323 standard, 

Another module in the wireless core network 1 1 is a media gateway control Amotion 
(MGCF) module 42 that provides (1) signaling conversion (e.g., ^IP-to-SS7 and vice versa 
via the MGCF 42 an^i T-SGW 43 interface) and (2) control of transcoding (e.g., speech data 
in RTP payload formats-to-PCM transcoding and vice versa in the MGW 34). 

The wireless core network 1 1 is capable of providing conventional packet data 
services, such as electronic mail, web browsing, file transfer, and so forth, for the mobile 
stations 16, .18, 20 and 22. Such data services may be provided for communications sessions 
between a mobile station and an endpoint coupled to the packet data network 28 or PSTN 36. 
The wireless core network 1 1 is also capable of providing packet-switched voice and other 
real-time conmiimications between the mobile stations 16, 18, 20 and 22 and endpoints 
coupled to the packet data network 28 or PSTN 36. As used here, "real-time 
commimications" refers to commimications in which data is exchanged on a substantially 
real-time basis between two endpoints (that is, the communication is delay intolerant). 
Examples of real-time data include voice data exchanged in a call (or telephony) session, 
video data exchanged in a video conferencing session, and so forth. 

In packet-switched communications, user data such as voice or other types of data are 
carried in packets, such as IP packets. In one embodiment, real-time data such as voice is 
converted to a Real-Time Protocol (RTP) format and carried as an RTP payload in a UDP 
packet that is encapsulated in an IP packet. RTP is described in RFC 1889, entitled "RTP: A 
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Transport Protocol for Real-Time Applications," dated January 1996. RTP defines end-to- 
end transport functions that are suitable for real-time data, such as audio, video, or other data: 

IP provides network layer flmctionality (riodie-to-node routing fiinctionality) for 
packet-switched communications over a network. Unlike circuit-switched networks, which 
provide a dedicated (connection-oriented paradigm) end-to-end channel portion (e.g., a time 
slot) for the duration of the call session, a packet-switched network that uses UDP as the 
transport layer and IP as the network layer is based on a connectionless oriented paradigm * 
(both end-to-end and node-to-node). Packets or other imits of data injected into a packet- 
switched data network may travel independently over any path (and possibly over different 
paths) to a destination point. For best effort quality of service, routing of packets in packet- 
switched conmnmications is based on destination addresses carried in IP packets. • 

The overhead portion of each packet that carries real-time data can be rather large due 
to the presence of several headers, including RTP and IP headers as well as a User Datagram 
Protocol (UDP) header. UDP is described in RFC 768, entitled *TJser Datagram Protocol," 
dated August 1980. One issue associated with carrying the protocol header information, 
which in one embodiment includes the RTP, UDP, and IP headers, is the increased bandwidth 
required to carry the overhead information. This reduces spectral efficiency over the air ^ 
interface (where bandwidth is a scarce and expensive commodity) between mobile stations 
and respective radio network controllers 12 and 14. In addition, channel coding and 
interleaving schemes that have been standardized for channels carrying circuit-switched voice 
traffic (without the protocol headers) may no longer be acceptable for packet-switched voice 
traffic encapsulated in packets containing the RTP, UDP, and IP header information. 
Consequently, new channel coding and interleaving standards may have to be developed and 
adopted, which is typically a time consuming and complex process. Also, radio equipment 
(such as base stations) may have to be replaced if new channel coding and interleaving 
schemes are developed. 

To address these issues, each end of the air interface between a mobile station and a 
radio network controller is capable of removing the RTP, UpP and IP headers from each 
packet before transmission of bearer traffic (e.g., voice data or other form of real-time data) 
over the air interface. Alternatively, instead of removing the protocol headers, a mobile 
station can simply choose not to generate the protocol headers. The receiving end then 
reconstmcts the RTP, UDP, and IP header information. Thus, what is sent over the air 
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interface is the bearer traffic itself without the overhead of the RTP, UDP, and IP headers. A 
benefit of. sending bearer traffic (e.g., voice-over-IP data) without protocol headers is that 
existing channel coding and interleaving schemes can be used. Also, spectral efficiency is 
enhanced since communication of overhead information in each and every bearer packet can 
be avoided. 

At least two alternative implementations of the protocol header 
removal/reconstruction scheme are possible. In a first implementation, the mobile station is a 
device (or plural devices) that requires the RTPAJDP/IP header information to be (1) 
constructed and then removed for voice data (or other forms of real-time data) transmitted on 
the uplink path fi-om the mobile station to the radio network controller, and (2) recqnstructed 
for voice data (or other forms of real-time data) received on the downlink path from the radio 
network controller to mobile station. In one example, the mobile station includes a computer 
(referred to as the TE device) coupled to a terminal (referred to as the MT device) capable of 
wireless communications with base station transceiver and a radio network controller. The 
combination of the TE and MT devices makes up the mobile station or user equipment (UE). 
In this example, the computer (or TE device) expects to receive voice packets (or other forms 
' of real-time packets) that contain the appropriate protocol headers (e.g., RTP/UDP/IP 
headers) for the packet-switched communications. 

In another arrangement of the first implementation, the mobile station is a single 
integrated device that includes software layers, including a protocol stack (e.g., RTP/UDP/DP 
stack), to receive packets that contain RTP/UDP/IP headers. 

In the first implementation, the mobile station removes RTP/UDP/IP header 
information from packets that are communicated on the uplink to the radio network 
controller. The mobile station reconstructs RTP/UDP/IP header to add to packets containing 
bearer data received on the downlink. 

In a second implementation, the mobile station can be a device such as a telephone 
that does not need to generate or reconstruct RTP/UDP/IP header information for voice data 
(or other forms of real-time data) transmitted on the uplink or received on the downlink, 
respectively. In this example, the mobile station includes the MT device without the TE 
device. Thus, bearer traffic, such as voice-over-IP data or other forms of real-time data, are 
passed directly to the other components of the mobile station for processing without 
reconstructing protocol headers. On the uplink, the mobile station either removes 
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RTP/UDP/IP header information from packets or never actually generates the RTP/UDP/IP 
header information so that bearer data is communicated on the uplink without protocol 
headers. 

In both implementations, the radio network controller (12 or 14) removes protocol 
headers associated with a packet-switched communications session before transmitting bearer 
traffic on the downlink. For example, IP packets containing bearer traffic are received from 
the SGSN 24. The radio network controller 12 or 14 removes the RTPAjDP/IP headers from 
the packets and commilnicates the bearer traffic without the protocol headers over the 
downlink of the air interface to the target mobile station. 
10 On the uplink j the radio network controller receives bearer traffic without protocol 

headers. It then reconstructs the protocol headers to add to packets containing the bearer 
traffic for communication to the SGSN 24. . 

Referring to Fig. 2, an IP packet 200 for carrying bearer traffic (e.g., voice traffic or 

other forms of real-time traffic) is illustrated. The packet 200 includes an IP header 202, a 

I 

15 UDP header 204, an RTP header 206, and a payload section 208t In the illustrated example, 
the payload section 208 carries the bearer traffic in RTP format. 

In a packet-switched communications session over an IP network that involves an 
exchange of real-time data (e.g., voice data), IP packets according to the format of packet 200 
are communicated between endpoints. At the transmitting endpoint, real-time data is 
20 converted into RTP format, and added as payload to the UDP/IP packet. The IP packet is 
communicated over the IP network to the receiving endpoint, where the real-time data is 
extracted. The IP header contains source and destination addresses that are used for routing 
the respective RTP/UDP/IP packet; however, to provide a quality of service that is better than 
best effort, other parameters such as UDP source and destination ports and protocol type 
25 mmiber may also be additionally used for routing. The UDP header identifies UDP source 

and destination ports, and the RTP header identifies characteristics of the real-time data in the 
payload. In the context of Fig. 1, the mobile station is one endpoint that is capable of 
participating in a packet-switched communications session with another endpoint (e.g., one of 
devices 30, 32 coupled to the packet data network 28, the media gateway 34, or another 
30 mobile station). 

To enable construction of the protocol header information, the IP, UDP, and RTP 
header information is communicated in configuration messages exchanged over the air 
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interface between a mobile station and a r^dio network controller as part of the call setup 
procedure. The RTP, UDP, and IP information carried in the configuration messages is 
stored by the mobile station and/or radio network controller. The stored information enables 
the mobile station and/or radio network controller to construct the RTP, UDP, and IP header 
information in response to the mobile station and/or radio network controller receiving bearer 
traffic (e.g., voice data or other form of real-time traffic). Thus, for example, in the uplink • 
direction, the mobile station removes (or does not generate) the r!tP, UDP, and IP headers 
and sends only bearer traffic over the air interface to the radio network controller. Upon 
receiving the bearer traffic firom the mobile station, the radio network controller accesses the 
stored configuration information to construct the IP, UDP, and RTP headers, with which IP 
packets carrying RTP payload can be constructed. Similarly, on the downlink, the radio 
network controller removes the RTP, UDP, and IP headers and transmits only bearer traffic 
over the air interface to the mobile station. According to one embodiment, the mobile station 
accesses stored configuration information to reconstruct the RTP, UDP, and IP header 
information for recreating IP packets. In another embodiment, the mobile station does not 

need to reconstmct the RTP, UDP, and IP header information. 

.1 

In one example, the configuration messages exchanged between the mobile stations 
and radio network controllers include the following: UPLINK PROTOCOL HEADER 
CONFIGURATION message, UPLINK PROTOCOL HEADER CONFIGURATION 
COMPLETE message, DOWNLINK PROTOCOL HEADER CONFIGURATION message, 
DOWNLINK PROTOCOL HEADER CONFIGURATION COMPLETE message, 
DOWNLINK PROTOCOL HEADER RECONFIGURATION message, and DOWNLINK 
PROTOCOL HEADER RECONFIGURATION COMPLETE message. 

The UPLINK PROTOCOL HEADER CONFIGURATION message is sent by a 
mobile station to a radio network controller and contains various predetermined RTP, UDP, 
and IP header infomiation that are to be part of the RTP/UDP/IP headers in packets 
communicated in packet-switched communications. The information in the UPLINK 
PROTOCOL HEADER CONFIGURATION message is used by the radio network controller 
to reconstruct the RTP/UDP/IP headers to add to packets originated by the mobile station. 
The UPLINK PROTOCOL HEADER CONFIGURATION message contains the following 
information elements: 
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INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS ■ 




RB Identity 


MP 


RTP/UDP/IP HEADER I>QFORMATION ELEMENTS 




EP Version 


MP 


Soiirce IP Address 


MP ' 


Destination IF Address 


MP 


DiffServ Code Point (DSCP) 


OP 


SourcQ UDP Port 


MP 


Destination UDP Port 


MP 


RTF Version 


OP 


RTF Payload Type (FT) 


MP 


RTF Synchronization Source Identifier (SSRC) 


MP 


RTF Sequence Number 


MP 


RTF Timestamp ' 


MP 


RTF Clock Frequency ' 


OP 



The first column identifies the information elements and the second column identifies 
whether each information element is mandatory (MP) or optional (OP). A Message Type 
information element identifies the type of message,- which in this case is the UPLINK 
PROTOCOL HEADER CONFIGURATION MESSAGE. An RB Identity information 
element identifies the radio bearer. 

The remaining information elements of the UPLINK PROTOCOL HEADER 
CONFIGURATION message are information elements carrying RTP, UDP, and IP header 
infomiation. An IP Version information element indicates the format of the IP header (e.g., 
10 IPv4 or IPv6). A Source IP Address information element contains the IP address of the 
source endpoint, in this case the mobile station. A Destination IP Address information 
element identifies the IP address of the destination endpoint, which can be the media gateway 
34, an endpoint coupled to the packet data network 28, or another mobile station. 

A Diff-Serv Code Point (DSCP) information element identifies the DSCP value. 
15 According to the differentiated services (Diff-Serv) quality of service (QoS) framework, the 
DSCP selects the per-hop behavior that k packet experiences at each node (e.g., a router) 
along a network path. The value of DSCP that is contained in each IP packet specifies a 
desired level of services. The Diff-Serv model employs a reservation-less mechanism for 
providing differentiated classes of services for network traffic. Diff-Serv is described in RFC 
20 2474, entitled "Definition of the Differentiated Services Field (DS Field) in the IPv4 and 
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IPv6 Headers," dated December 1998; and RFC 2475 entitled "An Architecture for 
Differentiated Services," dated December 1998. ' 

A source UDP Port information element specifies the UDP port of the source 
endpoint (the mobile station), A Destination UDP Port information element specifies the 
UDP port of the destination endpoint. 

Several RTP information elements are also carried in the UPLINK PROTOCOL 
HEADER CONFIGURATION message. An RTP Version information element contains the 
version (V) field that identifies the version of RTP. An RTP Payload Type (PT) information . 
element contains the payload type (PT) field of the RTP header, \yhich identifies the format 
of the RTP payload and determines its interpretation by a software application. An RTP 
Synchronization Source Identifiier (SSRC) information element contains the SSRC field of 
the RTP header. The SISRC field identifies th? synchronization source of a stream of packets. 
All packets fi"om a synchronization source form part of the same timing and sequence mmiber 
space, so a receiver groups packets by synchronization source fo^ playback. 

An RTP Seqijience Nimaber information element contains the sequence niunber of the 
RTP header. The sequence number for each RTP packet sent in a commimications session 
increments according to calculations based upon (1) the RTP Clock Frequency information 
element (e.g., 8,000 Hz for the AMR-NB speech codec or 16,000 Hz for the AMR-WB 
speech codec) and (2) the speech codec firame duration (e.g., 20 milliseconds for both the 
AMR-NB and AMR-WB speech codecs). The sequence number is used to detect packet loss 
and to restore packet sequence. 

An RTP Timestamp information element contains the timestamp field of the RTP 
header. The timestamp field reflects the sampling instant of the first octet or byte in the RTP 
data packet. The sampling instant is derived jfrora a clock that increments monotonically and 
linearly in time to allow synchronization and jitter calculations. In the UPLINK PROTOCOL 
HEADER CONFIGURATION message, the frequency of the clock is specified in an RTP 
Clock Frequency information element. 

The UPLINK PROTOCOL HEADER CONFIGURATION COMPLETE message is 
sent by the radio network controller to the mobile station to confirm the exchange of the 
header information (in response to receipt of the UPLINK PROTOCOL HEADER 
CONFIGURATION message). The message is shown below: 
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INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 



The UPLINK HEADER CONFIGURATION COMPLETE message contains a 
Message Type information element to indicate the type of message (in this case UPLINK 
PROTOCOL HEADER CONFIGURATION COMPLETE), and an RB Identity infonnation 

element to identify the radio bearer. 

In one embodiment, the DOWNLINK PROTOCOL HEADER CONFIGURATION 
message is sent by the radio network controller to the mobile station to enable the mobile 
station to reconstruct the RTP, UDP, and IP header infonnation. Note that the DOWNLINK 
PROTOCOL HEADER CONFIGURATION message is sent to mobile stations that are 
configured to reconstruct RTP/UDP/IP headers. For mobile stations that are not configured 
to reconstruct RTP/UDP/IP headers, communication of the DOWNLINK PROTOCOL 
HEADER CONFIGURATION message is not performed. 

The DOWNLINK PROTOCOL HEADER CONFIGURATION contains the 
following: 



INFORMATION ELEMENT/GROUP NAME 


INIEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 


RTP/UDP/IP HEADER INFORMATION ELEMENTS 




DiffServ Code Point (DSCP) 


OP 


RTP CSRC Count (CC) 


OP 


RTP Synchronization Source Identifier (SSRC) 


MP 


RTP Contributing Source Identifier (CSRC) 


OP 


RTP Sequence Number 


MP 


RTP Timestamp 


MP 



The DOWNLINK PROTOCOL HEADER CONFIGURATION infomiation element 
contains a Message Type infonnation element and an RB Identity information element. In 
addition, the message contains various RTP-related information elements and a QoS-related 
infomiation element. Note that the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message does not include IP and UDP soxurce and destination address 
and port information. Since the mobile station is UDP and IP-aware, the mobile station is 
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able to determine the IP address and UDP port information from call control signaling used to 
establish a packet-switched communications session (e.g., SIP signaling).. 

A Diff-Serv Code Point (DSCP) infomiation element (which contains QoS related 
information) contains the DSCP code for specifying a level of service for packets 
CQmmimicated in the communications session. An optional RTP CSRC Coxmt (CC) 
information element contains the CSRC count value in an RTP header. The CSRC Count ■ 
value contains the number of CSRC identifiers that are in a CSRC list (described below). 
The message also contains an RTP Synchronization Source Identifier (SSRC) information 
element as well as an RTP Contributing Source Identifier (CSRC) information elenient. The 
RTP CSRC information element contains a CSRC list (contained in an RTP header) that 
identifies the contributing sources for a payload contained in the packet. The number of 
CSRC identifiers in the CSRC Ust is specified in the RTP CSRC Count (CC) information 
element. Thus, in a multi-party call, the CRSC list identifies all parties that are involved in 
the call. In. a multi-party call, such as a conference call, voice data from multiple persons 
may be mixed together. The CSRC list enables the identification of possible soxirces of the 
combined voice data. The CSRC identifiers are typically inserted by RTP mixers. 

Other information elements in the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message include an RTP Sequence Number information element and an 
RTP Timestamp information element. 

A DOWNLINK PROTOCOL HEADER CONFIGURATION COMPLETE message 
is communicated in response to DOWNLINK PROTOCOL HEADER CONFIGURATION 
message, and contains the following elements. 



INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 



Once a packet-switched call has been established and is ongoing, the possibility exists 
for either of the two parties to conference in additional parties. The multi-party call setup is 
done using SIP signaling (or other call control signaling). Once additional parties have been 
conferenced in, the downlink RTP packets from the multi-parties typically go through an 
RTP mixer, where the voice data from multiple sources are mixed into a single RTP packet. 
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In a two-party call, the downlink RTP packet header includes the standard 12 bytes' accoirding 
to RFC 1889. 

However, once additional parties have been conferenced in, the downlink RTP packet 
header increases in size since additional RTP fields are included in the RTP header. One 
field that is included is the CSRC count field (CC)- If the value of CC is zei;o, then the call is 
a two-party call. If the value of CC is one, then the call is a threcrparty call. Given CC = N, 
there will be N CSRC identifiers in the RTP packet header. The list of CSRC identifiers is 
present only when inserted by an RTP mixer. The presence of this list is indicated by the 
parameter CC. Thus, the radio network controller can continuously snoop or monitor the 
parameter CC in messages received from the SGSN 24 to determine if the RTP/UDP/IP 
information in the mobile station needs to be reconfigured due to the presence of additional 
parties in the call. . • 

The reconfiguration is performed by u6e of a DOWNLINK PROTOCOL HEADER 
RECONFIGURATION message, whose content is provided below: 



rNFOKMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 


RTP/UDP/IP HEADER INFORMATION ELEMENTS 




DiffServ Code Point (DSCP) 


OP 


RTP CSRC Count (CC) 


OP 


RTP Synchronization Source Identifier (SSRC) 


MP 


RTP Contributing Source Identifier 


OP 


RTP Sequence Number 


MP 


RTP Timestamp 


MP 



To acknowledge the DOWNLINK PROTOCOL HEADER RECONFIGURATION 
message, the mobile station sends a DOWNLINK PROTOCOL HEADER 
RECONFIGURATION COMPLETE message. The content of this message is provided 
below: 



INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 
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Referring to Fig. 3, a call setup procedure according to one embodiment is illustrated. 
In this embodiment, packet-switched call setup is performed using SIP messaging. The 
entities involved in the call setup include a mobile station (labeled UE), a radio network 
controller, the SGSN 24, the GGSN 26, the CSCF 40, the MGCF 42, and the media gateway 
34. It is assumed that the mobile station UE is the initiator of the call, with the target being a 
terminal coupled to the PSTN 36, such as telephone 38 in Fig. 1. For piirposes of the packet- 
switched call, the terminating endpoint is the T-SGW 43 (Fig. 1) foi" control signaling and the 
media gateway 34 for bearer traffic. Packet control signaling and bearer traffic is converted . 
to traditional circuit-switched control signaling and traffic for coromunication over the PSTN 
36. 

The mobile station first performs a radio resource control (RRC) connection setup (at 
, 100) with the radio network controller. Next, .the mobile station performs a GPRS attach 
procedure (at 102). The GPRS attach procedure is performed to inform the radio access 
network that the mobile station is available. Next, to activate a primary PDP (Packet Data 
Protocol) context, the mobile station sends (at 104) an Activate PDP Context request, which 
is processed by the SGSN 24 and the GGSN 26. The primary PDP context includes, among 
other things, the default QoS profile for the requested connection. As part of the primary 
PDP Context activation procedure, the SGSN 24 performs a radio access bearer assignment 
procedure to assign one or more radio access bearers to the mobile station. 

After the primary PDP context has been activated, a SIP registration procedmre is 
performed (at 106). The SIP registration procedxire is performed with the CSCF 40, which 
includes the SIP proxy. SIP registration is performed to set up the profile for the mobile 
station in the CSCF 40, so that the CSCF 40 is aware of the mobile station's existence as well 
as various configuration information associated with the mobile station. 

After SIP registration, the mobile station can initiate a packet-switched call by 
sending call setup messages (at 108). To initiate a call, the SIP INVITE request is sent, 
which includes the destination address of the terminal being called and indicates that the 
called terminal is being invited to participate in a calf session. Various acknowledgment 
messages, as defined by SIP, are also exchanged between the mobile station and the CSCF 
40. The SIP messages are routed through the CSCF 40 since the CSCF 40 acts as the SIP 
proxy. 
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Next, the mobile station initiates an activates secondary PDP context procedure (at 
1 10). A different QoS profile can be assigned in the secondary PDP Context to enable a 
higher level of service if desired for the bearer traffic (e.g., packet-switdhed speech data). 
After the activate secondary PDP context procedure, further SIP call setup messages are 
exchanged (at 1 12) between the mobile station and the CSCF 40. After all appropriate SIP 
messages haye been exchanged, an RTP bearer path is established (at 114). In the RTP 
^ bearer path, IP packets containing RTP payloads are exchanged. 

However, in. accordance with some embodiments of the invention, the RTPAJDP/IP 
header information is stripped before being communicated over the air interface between the 
10 mobile station and the radio network controller. Thus, for example, if the media gateway 34 
sends a packet containing RTP bearer data (at 116), the entire IP packet is not actually 
communicated across the air interface. As described above, the RTPAJP/IP headers are 
removed before being comrnunicated. 

Before that can occur, the radio network controller sends a DOWNLINK 
15 PROTOCOL HEADER CONFIGURATION message (at 1 1 8) to the mobile station, 

according to one implementation. Note that the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message may not be needed if the mobile station does not need to , 
reconstmct RTP/UDP/IP headers. The mobile station stores the configuration information (at 
120) carried by the DOWNLINK PROTOCOL HEADER CONFIGURATION message. The 
_20 mobile station then acknowledges the message by returning (at 122) a DOWNLINK 

PROTOCOL HEADER CONFIGURATION COMPLETE message to the radio network 
controller. Upon receiving the DOWNLINK PROTOCOL HEADER CONFIGURATION 
COMPLETE message, the radio network controller sends the bearer data (received from the 
media gateway 34) over the air interface (at 124) to the mobile station. The bearer data is 
25 sent without the RTPAJDP/IP headers, which have been removed by the radio network 
controller. 

Similarly, if the mobile station desires to transmit bearer data targeted for the media 
gateway 34, it sends the bearer data without the RTP/UDP/IP header information. Before 
doing so, the mobile station sends (at 126) an UPLINK PROTOCOL HEADER 
30 CONFIGURATION message to the radio network controller. The radio network controller 
then stores (at 128) the configuration infomiation carried by the UPLINK PROTOCOL 
HEADER CONFIGURATION message. In response, the radio network controller returns (at 
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130) an UPLINK PROTOCOL HEADER CONFIGURATION COMPLETE message to the 
mobile station. At this point, the mobile station is able to remove RTP/UDP/IP header 
information so that only bearer data is conimimicated across the air interface to the radio 
network controller. Upon receipt of the bearer data, the radio network controller is able to 
reconstruct the RTP/UDP/IP headers, which are added to packets and commxmicated to the 
media gateway 34 through the SGSN 24 and GGSN 26. 

Referring to Fig. 4, an entity on the air interface (e.g., a mobile station that is able to 
reconstruct RTP/UDP/IP headers or a radio network controller) determines (at 304) if the 
entity has received inbound bearer traffic. If so, the entity reconstructs the RTP/UDP/IP 
headers (at 304). The RTP/UDP/IP headers are then added to IP packets that contain the 
bearer traffic (at 306). The IP patkets are communicated (at 308) to the target (which may be 
a node or terminal coupled to a network, such as the SGSN 24, or some software appUcatipn 
or other element within the entity). 

Referring to Fig. 5, the procediire for transmitting bearer data is illustrated. If the 
entity (either the mobile station or radio network controller) detects receipt of outboimd 
bearer traffic (at 402), which may be from a node or terminal coupled to a network or from an 
internal resoiuce, the entity removes (or does not generate) RTP/UDP/IP headers for the 
bearer data. The bearer data is then transmitted (at 406) without the RTP/UDP/BP headers 
over the air interface. 

Referring to Fig. 6, various components of the mobile station (referred to as 500) and 
radio network controller (referred to as 502) are illustrated. The mobile station 500 includes 
a lower physical layer 504, referred to as a radio frequency (RF) layer. The RF layer 504 is 
responsible for the RF signaling protocol between the mobile station and the radio network 
controller over an air interface or wireless link 506. Above the RF layer 504 is a mediimi 
access control (MAC) layer 508, The MAC layer 508 controls the access signaling (request 
and grant) procedures for the radio channel. Above the MAC layer 508 is a radio link control 
(RLC) layer 510. The RLC layer 510 provides a radio-solution-dependent reUable link. 

Further layers are defined above the RLC layer 510. In the illustrated example, such 
layers are referred to as a mapping protocol layer(s) 512, which are typically part of the 
Packet Data Convergence Protocol (PDCP) layer in UMTS. The PDCP layer is responsible 
for header compression/decompression. For example, according to GPRS the mapping 
protocol layer 512 includes an SNDCP (subnetwork dependent conversion protocol) layer. 
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The SNDCP layer maps network-level characteristics onto the characteristics of the 
underlying network and is responsible for header compression and decompression. Further 
layers may also be present, although not shown. 

On the other hand, according to UMTS, the mapping protocol layer 512 includes a 
packet data conversion protocol (PDCP) .layer. The PDCP layer maps higji-level 
characteristics onto the characteristics of the xmderlying radio-interface protocols and is 
responsible for header compression and decompression. PDCP provides protocol 
transparency for higher-level protocols. PDCP supports IPv4, IPv6, and PPP. 

Above the mapping protocol layer 512 is a UDP/IP stack 514. The mobile station 500 
also includes a SIP stack 516 for processing SIP control signaling. The SIP 516 interacts 
with one or more software applications 518. For example, the appUcations 518 may include 
user interface applications that allow a user to make phone calls. For bearer traffic, data is 
routed through an RTP layer 520. For outboimd traffic, the RTP layer 520 converts the 
bearer data into RTP format. For inbound traffic, the RTP layer 520 extracts RTP payload. 

The RTP bearer data is passed through a coder/decoder (CODEC) 524. The CODEC 
524 communicates through an analog-to-digital converter 526 to convert outbound data into 
analog format and to convert inboimd analog data into digital format. The A/D converter 526 
communicates with an I/O device 528, such as a speaker and microphone. 

The mobile 500 also includes a header control module 522, which is responsible for 
constructing RTP/UDP/IP information for inbound traffic (according to one arrangement). 
The header control module 522 is also responsible for causing the removal of RTP/UDP/IP 
header information (or alternatively, making sure that the RTP/UDP/IP information is not 
generated) for outboimd traffic. 

The various layers and modules in the mobile 500 can be implemented as software, 
hardware, or a combination of both. Software is executable on a control unit 530, which is 
coupled to a storage unit 532. The storage xmit 532 stores various data, such as header 
configuration information 534, and instructions of software. The header configuration 
inforaaation 534 is derived fi-om the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message or DOWNLINK PROTOCOL HEADER 
RECONFIGURATION message that is received from the radio network controller 502. 

The radio network controller 502 includes an RF layer 540, an MAC layer 542, and 
an RLC layer 544. The radio network controller 502 also includes a relay fimction 546 that 
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forwards data received from one node to the next node in the route. In the radio network 
controller 502, the relay function 546 forwards data between the interface to the wireless link 
506 and the interface to the SGSN 24, which is made up of a physical layer 552 (or LI layer) 
and upper layers 550. 

The radio network controller 502 also includes a header control module 548 that is 
responsible for removing and reconstructing RTP/UDP/IP headers. The various layers in the 
radio network controller 502 can be implemented in software, hariiware, or a combination 
thereof. Software is executable on a control unit 554, which is coupled to a storage unit 556. 
The storage unit stores various data (including header configuration information 558) and 
instructions of software. The header configuration information 55i8 is derived from ,UPLINK 
PROTOCOL HEADER CONFIGURATION messages. Note that the radio network 
controller 502 can store header configuration information 558 of multiple mobile stations. 

The various devices and systems discussed each includes; various software routines or 
modules. Such software routines or modules are executable on corresponding control units. 
Each control unit includes a microprocessor, a microcontroller, a processor card (including 
one or more microprocessors or microcontrollers), or other control or computing devices. As 
used here, a "controller" refers to a hardware component, software component, or a 
combination of the two. Although used in the singular sense, a "controller*' can also refer to 
plural hardware components, plural software components, or a combination thereof. 

The storage units referred to in this discussion include one or more machine-readable 
storage media for storing data and instructions. Hie storage media include different forms of 
memory including semiconductor memory devices such as dynamic or static random access 
memories (DRAMs or SRAMs), erasable and programmable read-only memories 
(EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and 
flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic 
media including tape; and optical media such as compact disks (CDs) or digital video disks 
(DVDs). Instructions that make up the various software routiiies or modules in the various 
devices or systems are stored in respective storage units. The instructions when executed by 
a respective control unit cause the corresponding device or system to perform programmed 
acts. 

The instructions of the software routines or modules are loaded or transported to each 
device or system in one of many different ways; For example, code segments including 
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instructions stored on floppy disks, CD or DVD media, a hard disk, or transported through a 
network interface card, modem, or other interface device are loaded into the device or system 
and executed as corresponding software routines or modules. In the loading or transport 
process, data signals that are embodied in carrier waves (transmitted over telephone lines, 
network lines, wireless links, cables, and the like) communicate the code segments, including 
instructions, to the 4evice or system. Such carrier waves aire in the form of electrical, optical, 
acoustical, electromagnetic, or other types of signals. 

While the invention has been disclosed with respect to a limited nuniber of 
embodiments, those skilled in the art will appreciate numerous modifications and variations 
therefrom. It is intended that the appended claims cover such modifications and variations as 
fall within the true spirit and scope of the invention. 
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What is claimed is: 

1 1 . A method of communicating data over a wireless link between a mobile 

2 station and a wireless access system^ comprising: 

3 commvmicating, over the wireless link, control signaling for setting up a 

4 packet-switched communications session between the mobile station and an endpoint; 

5 . communicating packets containing real-time data over thie wireless link; and 

6 removing at least one protocol header associated with packet-switched 
communications from each packet before communicating the packet over the wireless link. 



2. The inetiiod of claim 1 , wherein removing the at least one protocol header is 
performed by a radio network controller. 

1 3. The method of claim 2, wherein removing the at least one protocol header is 

2 performed by a GSM/EDGE radio access network (GERAN) radio network controller. 

■I . , 

1 4. The method ofclaim 2, wherein removing the at least one protocol header is 

2 performed by a UMTS radio access network (UTRAN) radio network controller. 

1 5. The method of claim 1, wherein removing the at least one protocol header is 

^ performed by the mobile station. 

1 6. The method ofclaim 1, wherein removing the at least one protocol header 

^ comprises removing one or more of an Internet Protocol header, User Datagram Protocol 
header, and Real-Time Protocol header. 

1 7. The method of claim 1 , wherein communicating the packets containing real- 

2 time data comprises communicating packets coiitaining voice data. 
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1 8. Computer program product comprising at least one storage medium containing 

2 instructions that when executed cause a system to perform a method comprising: 

3 ' receiving real-time data over a wireless link, the real-time data associated with 

4 a packet-switched communications session; 

5 constructing at least one protocol header for the packet-switched 

6 - commimications session; and 

7 , communicating the at least one protocol header and the real-time data in 

packets in the packet-switched communications session. 

1 9, The computer program product of claim 8, wherein constructing the at least 

one protocol header comprises constmcting an Internet Protocol header. • 

1 10. The computer program product of claim 8, wherein constmcting the at least 

2 one protocol header comprises constructing a User Datagram Protocol header. 

1 11. The computer program product of claim 8, wherein constructing the at least 

■ I 

2 one protocol header comprises constmcting a Real-Time Protocol header. 

1 12. The computer program product of claim 8, wherein the method further 

2 comprises receiving a first configuration message containing information relating to the at 
least one protocol header. 

1 13. The computer program product of claim 12, wherein the method comprises 

constmcting the at least one protocol header based on the information in the first 

3 configuration message. 

1 14. The computer program product of claim 13, wherein the method fiirfher 

2 comprises: 

3 sending real-time data over the wireless link to an entity; and 

4 sending a second configuration message to an entity coupled oVer the wireless 

5 link to enable construction of protocol headers for real-time data sent by the system to the 

6 entity. 
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1 15. The computer program product of claim 1 4, wherein the method further 

2 comprises sending a reconfiguration message to indicate a change in the packet-switched 

3 communication session. 

1 16. The computer program product of claim . 15, wherein the method comprises 

2 - sending the reconfiguration message to indicate addition of another party to the packet- 

3 switched communications session. 

1 1 7. A system for use in a wireless communication comprising: 

2 an interface to a wireless link; , 
a storage module to store information relating to a packet-switched 

4 commimications session between a mobile station and another endpoint; 

5 the interface to receive real-time data associated with the packet-switched 
'6 communications session; and 

7 a controller adapted to construct at least one protocol header associated with 

8 the packet-switched conunimications session based on the information and to commimicate 

9 packets containing the at least one protocol header and the real-time data. 

1 18. The system of claim 17, wherein the controller is adapted to receive a 

2 configuration message containing the information, * 



1 19. The system of claim 1 8, wherein the configuration message contains at least 

2 one of Intemet Protocol header information. User Datagram Protocol header information, and 
Real-Time Protocol header information. 



1 20. The system of claim 1 8, wherein the controller is adapted to transmit real-time 

2 data that is part of the packet-switched commimications session to an entity over the wireless 

3 link. 

1 21. The system of claim 20, wherein the controller is adapted to further 

2 communicate a second configuration message to the entity, the second configuration message 
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containing infonnation to enable the entity to construct protocol headers for the transmitted 
real-time data. 
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